Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000006_owner-urn-ietf _Sun Nov 3 01:56:31 1996.msg

Internet Message Format | 1997-02-19 | 9KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA15524 for urn-ietf-out; Sun, 3 Nov 1996 01:56:31 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA15517 for <[e-mail]>; Sun, 3 Nov 1996 01:56:23 -0500
Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA16634  (mail destined for [e-mail]); Sun, 3 Nov 96 01:56:20 -0500
Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA25490; Sun, 3 Nov 1996 00:51:41 -0600 (CST)
Date: Sun, 3 Nov 1996 00:51:41 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Message-Id: <[e-mail]>
To: Terry Allen <[e-mail]>
Cc: [e-mail]
Subject: Re: Names and Locations (was [URN] some comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Daniel LaLiberte writes:
 > | OK, what is a location?
 > | ...  Is it the
 > | domain name of the server, together with the path within the server?
 > | That's getting closer to the abstraction that URLs provide.  Is the
 > | location, in fact, the URL itself?

Terry Allen writes:
 > No, the URL is neither the location nor the resource, but the
 > name of a location, or a name of a location that may be resolved
 > on the fly.  The location is not the resource; the name of the
 > location is not the name of the resource.

On the face of it, this is sounding rather strange.  First, I agree
that the URL is not the resource itself (who would say that it is?
from your comment at the end, I think you think I said that).

Saying a URL is "the name of a location" is almost the same as "a URL
identifies a location".  The extra indirection of going from URL to
identifier to location, rather than URL to location, seems unnecessary,
and perhaps it is irrelevant semantics.  What is relevant is that you
guys make a distinction between URLs and URNs, and it is a
distinction founded on a misunderstanding.  I've been trying to dig
through to get to the heart of that misunderstanding.

 > | Consider caches.  The resolution of a URL via a cache proxy may find
 > | the resource in the cache rather than in some remote server.  What is
 > | "the location" of the resource in that case?
 >
 > What is "the resource"?  Any copy of what you got back from resolution?
 > then its location is both in the cache and on the remote server.
 > Is it "the copy I got back from resolution"?  then its location
 > is in the cache.

But the very same URL was used to retrieve the resource either from a
cache or from a remote server.  So what "location" is the URL
identifying when the resource actually lives in multiple places - the
very same URL may be used to fetch the resource from any of those
places?  Notice you first say that a URL identifies (or names) the
location of a resource, and then we find out that there are really
multiple locations identified by the URL.  But that is supposed to be
the job of URNs.  So why do we need URNs?

 > | Here is an example of how what is thought of as a location really
 > | turns out to *be* a name (as in persistent location).  Take a normal
 > | http URL such as http://www.ncsa.uiuc.edu/.  Instead of using normal
 > | HTTP to resolve the URL, or to look it up in a cache, let's set up a
 > | NAPTR-based "http" naming authority.  Under that branch of the name
 > | space, we could ask the appropriate DNS server to look up
 > | 'www.ncsa.uiuc.edu' to find out where a server is currently located
 > | and what "resolution protocols" are currently supported.
 >
 > That is a coincidence of naming:  you made the name of the resource
 > (qua URN) be the same as the name of its location.  But
 >    urn:http://www.ncsa.uiuc.edu/
 > and
 >    url:http://www.ncsa.uiuc.edu/
 > name two different things.

I used "http://www.ncsa.uiuc.edu/" for both, no "urn:" or "url:" for
either.  (BTW, If "urn:" is optional, then
"urn:http://www.ncsa.uiuc.edu/" has identically the same meaning - it
is an equivalent identifier).  A client can resolve
"http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or
something else.  This is the very same identifier, not two identifiers
with the same character representation.  Calling it two identifiers
and saying one is a name and the other is [the name of] a location is
missing the whole point.

The point is a single identifier can, in fact, be resolved many
different ways by clients.  Some ways are more direct (e.g. HTTP) and
some are more indirect (e.g. NAPTR).  They are all resolution
mechanisms.  They all result, eventually, in the resource, or whatever
is being requested.


 > | We don't need to create a new kind of identifier to make a URL
 > | into a persistent location.

 > Which is not what you did in the example just given.

It is so.

 > You created a new name space and rules for using it that by design
 > produce a name that looks like a URL which, when resolved, will
 > give the same result.

The name space is just a vehicle for resolving the identifier.
Consider how a cache creates a name space for looking up resources
given http URLs (usually it's just a hash table, but imagine it
creates a similar hierarchy to model DNS and filesystems within
servers).  Would you claim that the cache is somehow making new
identifiers?

Here is, perhaps, the missing point: The persistence of a name space
is not a property of the identifiers - it is a property of the
mechanism used to resolve the identifiers.

You seem to be saying that the persistence is a property of URNs, and
thus names are obviously different from locations.  I am saying that
the persistence of URNs is due to resolution mechanisms such as the
NAPTR mechanism.  (It is also due to the naming authorities
guaranteeing that the names will behave properly if the appropriate
resolution mechanism is used.)

Since different mechanisms can be used to resolve the very same
identifiers, and since some mechanisms might provide persistence while
others do not, there is no point in distinguishing the identifiers as
either names or locations.

There is nothing inherent in identifiers themselves that makes them have
different properties, whether name-like or location-like.  It is how
the identifiers are created and used that gives them those properties.

>From that standpoint, http URLs are different from new classes of
identifiers that will be created under the URN name space(s).
I certainly recognize that we need more persistence in the resolution
process, and that is why we created the "path" resolution mechanism.
(In fact, I believe the NAPTR mechanism doesn't go quite far enough,
and agree with Larry in that regard.)

But it is not the identifiers themselves that need to be distinguished
based on the properties of the resolution mechanism.  For one class of
identifier, there might be two resolution mechanisms available, one
supports persistence and the other does not.  So are the identifiers
names or locations?  Irrelevant question.

 > | To summarize, both URLs and URNs have the following abstract
 > | resolution process in common:
 > | 1. Do some client-specific processing of the URI - maybe end there.
 > | 2. Look at the scheme name of the URI.  If it says "URN:" drop it and repeat.
 >
 > No, you have to branch into your "find URN" subprocess.

You could handle everything with "URN:" prefix with the same process,
but it is not required - you could just as well handle each URN
subscheme differently.  Or you could handle parts of a single name
space differently from the rest.

 > | 3. Look up the scheme in local table to find out what process should
 >
 > The local table will be different for URLs and URNs, will it not?

Not necessarily.  Each URL or URN scheme might have a different
process associated with it, or we could use just one process for
all schemes.

 > |    be invoked.  E.g. news URIs may use NNTP, http URIs may use HTTP,
 > |    cid URIs may use NAPTR-protocol.
 > | 4. Invoke the process identified by step 3.
 > | 5. If error results, exit.
 > | 6. If redirected to another URI, repeat whole process with that URI.
 > |
 > | An alternative to steps 2 and 3 would use more than just the scheme
 > | name to determine what process to invoke.  There are several other
 > | varients possible in the whole process, and each client or each user
 > | might do things differently.
 > |
 > | I hope I've made my postion very clear regarding names, locations, and
 > | the resolution process.
 >
 > That you see no difference between objects and their locations?

I really don't see how you got that.  When did I talk about the
difference between objects and their locations?

I see no difference between *names* and *locations* at least
regarding the identifiers themselves.

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/